Overall: Good design direction, but suggest refining the category taxonomy before merging.

The idea of separating table processes into different tabs is great. However, I think MAINTENANCE is too broad a category and we should consider a more precise taxonomy that better aligns with the nature of these operations.

Suggested Classification

Instead of a binary OPTIMIZING / MAINTENANCE split, I'd suggest a three-way classification:

Additionally, Sync Hive Tables is more of an internal implementation detail and probably should not be exposed to users in any tab.

Rationale

• "Maintenance" is too vague — compaction could also be considered "maintenance" in a broad sense.
• The operations currently under MAINTENANCE actually serve two distinct purposes: space reclamation (Expire/Clean) vs. metadata enrichment (Auto Create Tags). As we add more operations (e.g., statistics collection), this distinction will become more important.
• This three-way split aligns with industry conventions: Delta Lake has OPTIMIZE / VACUUM, Iceberg docs separate "rewrite" from "expire/remove".

Suggested Approach

For the backend API, I'd recommend defining three processCategory values upfront: OPTIMIZING, CLEANUP, PROFILING. This makes the API future-proof.

For the frontend, there are two pragmatic options:

1. Three tabs (Optimizing / Cleanup / Profiling) — cleanest separation
2. Two tabs for now (Optimizing / Cleanup) — merge Profiling into Cleanup since there's currently only one profiling operation (Auto Create Tags), and split it out later when more profiling operations are added

Either way, the endpoint could be generalized from /maintenance-types to something like /process-types?category=CLEANUP for better extensibility.

What do you think?

Overall: Good design direction, but suggest refining the category taxonomy before merging.

The idea of separating table processes into different tabs is great. However, I think MAINTENANCE is too broad a category and we should consider a more precise taxonomy that better aligns with the nature of these operations.

Suggested Classification

Instead of a binary OPTIMIZING / MAINTENANCE split, I'd suggest a three-way classification:

Category Purpose Current Operations Future Extensions
OPTIMIZING Performance optimization (data reorganization) Minor / Major / Full Compaction Clustering, Sort Rewrite
CLEANUP Space reclamation & lifecycle management Expire Snapshots, Expire Data, Clean Orphan Files, Clean Dangling Delete Files VACUUM, Remove Old Metadata
PROFILING Information enrichment & metadata augmentation Auto Create Tags Collect Statistics, Build Index
Additionally, Sync Hive Tables is more of an internal implementation detail and probably should not be exposed to users in any tab.

Rationale

• "Maintenance" is too vague — compaction could also be considered "maintenance" in a broad sense.
• The operations currently under MAINTENANCE actually serve two distinct purposes: space reclamation (Expire/Clean) vs. metadata enrichment (Auto Create Tags). As we add more operations (e.g., statistics collection), this distinction will become more important.
• This three-way split aligns with industry conventions: Delta Lake has OPTIMIZE / VACUUM, Iceberg docs separate "rewrite" from "expire/remove".

Suggested Approach

For the backend API, I'd recommend defining three processCategory values upfront: OPTIMIZING, CLEANUP, PROFILING. This makes the API future-proof.

For the frontend, there are two pragmatic options:

1. Three tabs (Optimizing / Cleanup / Profiling) — cleanest separation
2. Two tabs for now (Optimizing / Cleanup) — merge Profiling into Cleanup since there's currently only one profiling operation (Auto Create Tags), and split it out later when more profiling operations are added

Either way, the endpoint could be generalized from /maintenance-types to something like /process-types?category=CLEANUP for better extensibility.

What do you think?

Your feedback is very helpful. Thank you very much. The new commit has been fixed and the latest screenshots have also been updated above. The changes are as follows：
Changes:

• Add ProcessCategory enum with OPTIMIZING, CLEANUP, PROFILING
• Replace getTableMaintenanceTypes() with getTableProcessTypes(category)
• Remove excludeTypes parameter from TableProcessMapper.listProcessMeta()
• Merge /optimizing-types and /maintenance-types into /process-types endpoint
• Split Maintenance.vue into Cleanup.vue and Profiling.vue
• Update HudiTableDescriptor and PaimonTableDescriptor
• Fix TestIcebergServerTableDescriptor to pass processCategory parameter

BREAKING CHANGE:

• Removed /optimizing-types and /maintenance-types REST
  endpoints.
• Use /process-types?processCategory=OPTIMIZING|CLEANUP|PROFILING.
• SPI method getTableMaintenanceTypes() replaced by getTableProcessTypes().

The current design introduces two static methods (resolveCategoryTypes and matchProcessCategory) in FormatTableDescriptor, where each descriptor implementation maintains its own type lists and passes them as arguments. This is a bit awkward — the routing logic is split between the caller and the interface.

A cleaner approach would be to add an instance method to the interface:

/**
 * Returns the list of process type names belonging to the given category.
 * Used internally to filter processes by category.
 */
default List<String> getProcessTypesByCategory(String processCategory) {
    return Collections.emptyList();
}

Each descriptor overrides this to return its own category-to-types mapping:

// MixedAndIcebergTableDescriptor
@Override
public List<String> getProcessTypesByCategory(String processCategory) {
    return FormatTableDescriptor.resolveCategoryTypes(
        processCategory, OPTIMIZING_TYPE_LIST, CLEANUP_TYPE_LIST, PROFILING_TYPE_LIST);
}

// HudiTableDescriptor / PaimonTableDescriptor
@Override
public List<String> getProcessTypesByCategory(String processCategory) {
    if (ProcessCategory.OPTIMIZING.getName().equalsIgnoreCase(processCategory)) {
        return OPTIMIZING_TYPES;
    }
    return Collections.emptyList();
}

Then getOptimizingProcessesInfo just calls descriptor.getProcessTypesByCategory(processCategory) without needing to know about the three separate lists. The two static helpers can be removed or made private.

This keeps the "what types belong to my category" knowledge encapsulated in each descriptor, and makes the interface easier to extend when new categories are added.

The current design introduces two static methods (resolveCategoryTypes and matchProcessCategory) in FormatTableDescriptor, where each descriptor implementation maintains its own type lists and passes them as arguments. This is a bit awkward — the routing logic is split between the caller and the interface.

A cleaner approach would be to add an instance method to the interface:

/**
 * Returns the list of process type names belonging to the given category.
 * Used internally to filter processes by category.
 */
default List<String> getProcessTypesByCategory(String processCategory) {
    return Collections.emptyList();
}

Each descriptor overrides this to return its own category-to-types mapping:

// MixedAndIcebergTableDescriptor
@Override
public List<String> getProcessTypesByCategory(String processCategory) {
    return FormatTableDescriptor.resolveCategoryTypes(
        processCategory, OPTIMIZING_TYPE_LIST, CLEANUP_TYPE_LIST, PROFILING_TYPE_LIST);
}

// HudiTableDescriptor / PaimonTableDescriptor
@Override
public List<String> getProcessTypesByCategory(String processCategory) {
    if (ProcessCategory.OPTIMIZING.getName().equalsIgnoreCase(processCategory)) {
        return OPTIMIZING_TYPES;
    }
    return Collections.emptyList();
}

Then getOptimizingProcessesInfo just calls descriptor.getProcessTypesByCategory(processCategory) without needing to know about the three separate lists. The two static helpers can be removed or made private.

This keeps the "what types belong to my category" knowledge encapsulated in each descriptor, and makes the interface easier to extend when new categories are added.

Thank you very much. The new commit has been fixed it.